The present invention is generally directed to memory access, and in particular to accessing data storage devices with enhanced functionality.
Memory devices (e.g., disk drives, flash cards, etc.) are increasingly requiring extended command sets to provide enhanced functionality and specialized features. For example, many applications for memory devices require encryption services, extended access/ownership capability, copyright information, leasing and other time based parameters, and so on. The term memory device is meant to encompass a broad range of devices for storing data, and will be used interchangeably with data storage device throughout the discussion which follows.
FIG. 6 shows aspects of a conventional system architecture for memory devices. A memory device 602 is typically connected to a host device 612 via a suitable interface 604 (e.g., bus, slot, etc.). The interface 604 represents both the pinouts or connectors provided in the memory device, and the bus or slot that is provided in the host device to which the memory device is connected. Conventionally, a memory device includes a memory component 622, and control logic 624 which provides an interface to the memory component. The memory component can be semiconductor memory, magnetic memory, and or optical memory, depending on the type of memory device. For example, a flash memory device typically comprises a semiconductor memory as the memory component 102. A disk storage memory device typically employs magnetic media as the memory component 102. Optical storage technologies are a relatively new technology for disk storage memory devices where the memory component comprises, for example, magneto-optical media.
Software on the host side 612 typically comprises one or more host applications 600 executing on top of an operating system (OS) 608. Typically the host applications make various system calls into the OS. Some of the system calls involve accessing the memory device 602. Higher level functionality can be provided to an application via an application programmer's interface (API) 664.
The OS 608 includes a set of device drivers (device driver library) 606 for I/O with the memory device 602. The device drivers set up the data that is sent to the device to perform certain tasks. This might include writing a command selected from the command set of the device to a command register in the device. Device driver function calls 662 are the software interface between the OS and the device drivers. OS system calls which access a device are implemented via the device drivers. Though many I/O operations with a device are common among memory devices (e.g., read, write), each type of a particular kind of device (e.g., flash memory, RAM, static RAM) typically operates differently from other types of devices, so that different device drivers may be needed for each type of device. Moreover, one kind of memory device (e.g., disk drive storage) might have different kinds of operations (e.g., seek) not found on other kinds of devices (e.g., flash memory). Thus, device drivers are written specifically for each device for operation with a particular device.
Adding new functionality to enhance an intelligent memory device conventionally means extending the existing command set of a device to include new commands for accessing the new functions. This typically requires the addition of extended capability across multiple components of the system architecture. Consider the addition of a new feature(s), e.g., data encryption, in the memory device 602. First, the command set of the device must now include one or more additional commands for the new feature. This includes providing processing capability 632 or other suitable logic to perform the new feature. Extended control logic 634 is typically required in the memory device to provide access to the new feature. For example, the extended control logic can implement an extension of the device's command set, allowing access to the new feature. In order to access the extended command set, new or modified device driver code 633 must be written. The new device drivers might comprise modifications of existing drivers, or maybe even the addition of completely new drivers if the feature is completely new functionality in the device. The device driver function calls 662, likewise may have to be modified along with corresponding modifications in the OS to accommodate the modified drivers.
The API 664 may have to be expanded to provide access to the new functionality. This might involve new API calls if the feature is completely new to the device. And of course, new application code 631 must be included in the host applications 600 to use the added functionality of the memory device.
Host devices 612 are built on a variety of processing hardware and software platforms. Device drivers for an OS running on one hardware platform are likely to be different from the device drivers for the same OS running on another hardware platform. Conversely, the device drivers written for an OS running on a given hardware platform are likely to be different from the device drivers written for a different OS running the same hardware platform. In fact, different device drivers may be needed on the same software/hardware platform if different slot hardware is used (e.g., PocketPC).
Device drivers are platform specific, and sometimes within a platform, a different device driver is needed based on the components installed. Device drivers therefore have to be modified; and in many instances, the OS needs to be extended. The constant development, rewriting, and testing of device drivers typically results in a business decision to support only a few platforms because of the time and expense that must be invested for new drivers.
Though software development technology exists to facilitate the addition of an extended command set to a memory device, device driver source code and build environments are hard to procure, and having to do so for multiple environments complicates the problem. There are vendors who provide solutions for writing portable device drivers. However, the availability of robust solutions, and the widespread adoption of these solutions has not yet been realized, especially in the memory card space. Moreover, device drivers operate at the OS level and thus have access to vital aspects of the operating environment. It is therefore easy to “break” the entire system if a device driver is not properly written. Due to the dependence on too many vendors to bring a technology to market, there is a delay in the delivery of new memory device technologies to the consumer; and in some cases the new technology may never migrate to certain platforms.